Git has two repository types,
local and remote. The local repository is on your own
machine, so you have direct access to it. The remote repository is usually
a centralized server and is entirely optional. We can save the changes that we
made locally on this remote server. The remote repository is very useful when
you want to have a backup of your data in case your computer breaks or
when you're working with a team. Teammates can initialize their own local
repository on their own computers and simply pull the data from the remote
repository in order to start working on your project. When one of the team members has made some
changes, they can push these changes to the remote repository in order to keep
your local and remote repository in sync. You can then pull these changes from
the remote repository into your local repository. The local repository actually
consists of three stages, the working area are all
your active changes. Git doesn't know what to do with them yet, it just knows that these
files contain some updates. The staging area contains new
changes that will soon be committed. And then there are the committed files. Previously we looked at the use
case of git and we saw that people could add their change and
save new states of the project each time. What we're actually looking
at here are commits. People can commit their changes in order
to add version control to the project. The files that should be included
in the commit are first added to the staging area. A commit gets created when a developer
actually commits those files.